perm filename HSTHST.PRO[DLN,MRC]2 blob
sn#314818 filedate 1977-11-04 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00020 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00003 00002 DIALnet memo #2
C00005 00003 CONVENTIONS USED IN THIS DOCUMENT
C00007 00004 PREFACE
C00011 00005 INTRODUCTION
C00016 00006 GOALS
C00019 00007 THE DIALNET CONTROL PROGRAM
C00024 00008 DATA FLOW AND ERROR DETECTION
C00030 00009 DATA FLOW AND ERROR DETECTION (continued)
C00033 00010 CHECKSUM ALGORITHM
C00036 00011 PACKET FORMAT
C00039 00012 OP CODES
C00044 00013 OP CODES (continued)
C00049 00014 OP CODES (continued)
C00051 00015 ESTABLISHING AND BREAKING A CONNECTION
C00056 00016 EXAMPLES OF DIALNET INTERACTIONS
C00058 00017 GLOSSARY
C00063 00018 GLOSSARY (continued)
C00066 00019 REFERENCES
C00069 00020 ACKNOWLEDGEMENTS
C00070 ENDMK
C⊗;
DIALnet memo #2
SAILON silver girl
DIALnet Protocols
(or, the Protocols of DIAL)
Host-Host Protocols
Mark Crispin
11/4/77
These protocols are being developed as part of the DIALnet project at the
Stanford University Artificial Intelligence Laboratory supported by NSF grant
MCS 77-02080 with John McCarthy as Principal Investigator. The project is
described in a paper available online at ARPAnet host SU-AI as
DIALNE.MEM[DLN,MRC] (DIALnet Memo #1).
This is HSTHST.PRO[DLN,MRC] at ARPAnet host SU-AI (octal 13, decimal 11.).
CONVENTIONS USED IN THIS DOCUMENT
All numbers without an explicit base (ie, octal or decimal) specified
should be interpreted as octal unless the number is immediately followed by a
dot, in which case it is decimal. However, numbers with intervening spaces
every three digits should be treated as binary (the intervening spaces are used
to facilitate conversion to octal).
All three-digit octal numbers should be interpreted as representing an
8.-bit byte, with bits right-justified within the number (ie, from 000 to 377).
Bytes are expressed in the form as returned by the modem (ie, lsb first); ie,
105 is transmitted in the bit stream as 101 000 10.
All six-digit octal numbers should be interpreted as representing a 16.-bit
double-byte, with bits right-justified within the number (ie, from 000000 to
177777). Double-bytes are expressed in the form returned by the modem (ie, low
order byte and lsb first); ie, 010041 is transmitted as 100 001 000 000 100 0.
PREFACE
"Aren't you glad you use DIALnet? Don't you wish everybody did?"
This document specifies a protocol for use in communication between Host
computers using the DIALnet protocols. In particular, it provides for
connection of independent processes in different hosts, control of the flow of
data of established connections, and other related functions.
Although self-contained, this document specifies only one of the DIALnet
protocols. In particular, while this protocol specifies how data is to be
transmitted in between processes on DIALnet, it does not define in what format
the data is to be sent, nor does it define how the processes are expected to use
the data received. It merely attempts to provide an error-free link between
processes.
This Host-Host protocol is the "second level", or secondary protocol used
on DIALnet. The primary protocol is the protocol of the dialing modems. The
Process-Process protocols, or tertiary protocols, are described elsewhere.
Questions concerning DIALnet protocols should be addressed to:
Mark Crispin
Stanford Artificial Intelligence Laboratory
1600 Arastradero Road
Stanford, California 94305
(415) 491-1407
MRC@SU-AI
Copies of all DIALnet-related correspondence should be sent to John
McCarthy (DIALnet principal investigator) and Les Earnest at the above US mail
address or via ARPAnet mail to JMC@SU-AI and LES@SU-AI.
It is the intent of the author that these protocols are both simple in
their implementation and powerful in their operation. Certainly a major design
consideration was to design protocols that ordinary mortals could implement on
their systems.
The intended audience of DIALnet ranges from fairly small to quite large
systems, however, DIALnet has been designed to be nice for medium sized
time-sharing systems, such as PDP-10's and DECsystem-20's.
INTRODUCTION
DIALnet provides a capability for geographically separated computers,
called hosts, to communicate with each other. The host computers typically
differ from one another in type, speed, word length, operating system, etc.
Each computer utilizes DIALnet via the ordinary phone lines and special modems
using the primary protocol.
This protocol, however, is insufficient to specify meaningful communication
between processes running in two dissimilar hosts. The processes must have some
agreement as to the method of initiating communication, the interpretation of
transmitted data, etc. While it is possible for individual pairs of hosts or
processes interested in communication with each other to establish private
protocols, it is more desirable for a DIALnet-wide set of standard protocols to
be established to minimize the amount of implementation effort involved in
DIALnet-wide communication.
Hence, a "layered" approach to communications protocols similar to those of
the ARPAnet are specified here. The primary layer is the protocol of the
dial-up modems. The secondary protocol, described here, is the host-host
protocol, which is used by all higher-level protocols. The tertiary protocols,
described elsewhere, include: (in approximate order of importance)
MAIL Sending and receiving letters between different users at different
hosts. These "letters" tend to be things like memos or such which are
read by the user at his/her convenience instead of immediately.
SEND Person-to-person immediate line at a time communication.
LINK Person-to-person immediate character at a time communication.
INFO A general service providing information at the host, including access
information, currently logged-in users, how not-logged-in users may be
contacted, etc.
FTP File transfer protocol for reading, writing, and manipulating files at a
remote host.
TELNET Mapping of an arbitrary console keyboard/printer at the local host to a
DIALnet virtual terminal which communicates with a terminal server
process at the remote host. The remote host's server process maps the
virtual terminal's protocol into the host's own local terminal's
protocol. In this manner, users of one host can connect to another and
log in, etc. as if they were at a local console at the remote host.
There are probably going to be several levels of TELNET; the first and
simplest will be a simple "connection" like a phone connection with no
options. Others, such as ARPAnet-compatible TELNET (ARPATLNT), display
SUPDUP (SUPDUP), and other forms of remote terminal access will be
provided.
GOALS
1. An essentially error-free data link. By this I mean no undetected errors,
no missed data, and error correction which is invisible to the user
process.
2. Simple enough to put into small systems yet powerful enough to handle
sophisticated data communications.
3. Non-hairy implementation.
4. Optimal for mailing and other message communication purposes, then for file
transfer, then for telnetting. DIALnet is intended primarily for
communications between two hosts where the physical amount of data
transmitted and the actual connect time is relatively short.
5. Efficient data communication with no deadlock situations.
6. Allow for upwards-compatible extensions (such as multiplexed connections) in
future incantations of DIALnet.
7. Allow for private protocols to be established.
NON-GOALS
1. Multiplexed connections. This is impractical with present technology; it
will be reconsidered in the future.
2. Direct interface with other networks. The MAIL protocol will consider this
problem though.
3. The comprehensive features of the ARPAnet or other high-bandwidth networks.
DIALnet will provide the same USER services as a network such as the
ARPAnet; but it is important to realize that DIALNET is a low-bandwidth
communication protocol and not a physical network such as the ARPAnet.
4. Low-level handling of byte sizes of other than 8.-bit bytes.
5. Variable-format packets. It makes everything simpler to use fixed format.
6. Encryption at the host-host level.
7. Use of non-ASCII character sets at the host-host level.
THE DIALNET CONTROL PROGRAM
The DIALnet control program is the program (or set of programs--it can be
many processes) within each host which is responsible for establishing and
breaking connections as well as controlling the data flow over the connections.
Normally, the DCP will be part of the operating system or the front end
processor, although it could be an I/O subroutine in a user program. However,
it is suggested that on any sort of timesharing or multiprocessing system that
there be a separate process which interfaces between the user process and the
"network"; this makes the programming task easier for the user (since the user
is given a data link with the DIALnet host-host protocol headers already parsed
out and all error handling already performed) and allows for a consistent
interface with other hosts.
For the DCP to perform its work, it must communicate with the DCPs running
on other hosts. To allow this, a rigidly formatted packet structure has been
established for messages exchanged between the individual DCP's. The format of
this packet is discussed later on.
Another concern which the DCP should handle is the problem of buffering and
allocation. The DCP can set a maximum number of bytes of tertiary data (ie, the
data part of an MSG packet) which may be sent before the connection becomes
"frozen", waiting for a further allocation. An allocation of zero bytes implies
infinite allocation in any ALL packet; infinite allocation specifies that no
"freezing" is to be done henceforth. Allocation must be established when the
connection is made otherwise it is assumed to be infinite. Once set to
infinity, it may not be set to a finite quantity.
The purpose of allocation is to allow hosts with limited buffering
capability to use the DIALnet facilities without having data overruns and the
resulting loss of efficiency in retransmitted packets. Note that allocation
does not affect retransmission, packet headers or trailers, or the data area of
any packets other than MSG packets. A host must be prepared to accept and
process non-MSG packets at any time.
This only covers tertiary data. The DCP normally should run at a high
enough priority to be able to handle all non-MSG packets coming in. If it
cannot, it still can win (sort of) by failing to acknowledge a packet which it
lost; eventually it will have to be retransmitted. It should be noted that this
is rather inefficient and it is best for the DCP to be a low-level process that
is guaranteed to be able to process non-MSG packets without buffering.
DATA FLOW AND ERROR DETECTION
All data is sent in the form of packets, which contain a packet header,
some data, and a packet trailer. The packet header serves to identify the type
of packet (ie, its functionality) and the size of the data area. The packet
trailer provides a checksum for the packet.
Packets have the same general format, illustrated on the PACKET FORMAT
page. They begin with a fixed start of packet code, followed by an op code,
followed by the rest of the packet contents, and terminated by a checksum and an
end of packet code. The reason for this rather inflexible scheme was to make
implementation as simple as possible and to provide a clear, unambigious format
for packets. Using this scheme it is possible for the same read-packet routine
to read all types of input packets.
Both the packet header and the packet trailer begin with a fixed value.
This is used in packet synchronization. The Start-Of-Packet (SOP) code is 227
and the End-Of-Packet (EOP) code is 226. These values were selected for two
reasons: (1) they are unlikely to occur frequently in ASCII data, and (2) they
are unlikely to be generated by line noise. If a byte which has the value of an
SOP or an EOP occurs within a packet, it must be quoted by a preceeding SOP.
All packets, except for acknowledgement (ACK) packets, must be acknowledged
with ACK. It is acceptable to send extra acknowledgements at any time; as an
acknowledgement also serves as a request for more packets. All packets except
for acknowledgement packets increment the packet number, which wraps around to
001 on overflow.
Packets must be received in sequence, with the exception of ACK and RST
packets. These op codes always take a packet number of 000, since they do not
use the normal data flow mechanism (RST initializes it). However, RST's must
still be acknowledged (ie, ACK 000 verifies a reset).
In the discussion below, timeout values are given. These times are the
maximum amount of time delay between the start of a wait for an event and the
time when the timeout action should be taken. It is possible not to use
timeouts by continuously transmitting, but it is rather inefficient.
For efficiency, the sender may send up to 3. packets before getting an ACK
for the first of the three (in other words, up to three packets may be awaiting
acknowledgement at any one time). In addition, there is a timeout of 10.
seconds, and if an acknowledgement is not received for any packet within that
time, transmission starts over with that packet.
The receiver must reply to every packet it receives with an ACK if the
packet was received successfully or an ERR if it was not. If transmission stops
within a packet and is not resumed within 15. seconds, the receiver flushes what
it has received of the packet so far and sends an ERR. In addition, if the
receiver has not received a new packet within 5. seconds after the end of the
previous packet, it should repeat the ACK.
If the receiver receives a packet it has already acknowledged, it should
ignore it and repeat the ACK. If an out-of-sequence packet is received, it
should send an ERR and discard that packet.
If the sender intends to "go idle" (ie, wishes to stop transmitting real
data for a while), it should send a NOP, which should be repeated every 5.
seconds. This assures the receiver that the sender is still up.
If no packets (good or otherwise) have been received from the sender in 30.
DATA FLOW AND ERROR DETECTION (continued)
seconds, the receiver should assume that the sender is dead, send an ERR, and
hang up. If no good packets have been received within 120. seconds, the
receiver should assume that the connection is faulty, send an ERR, and hang up.
The receiver is not obliged to wait for ACKs in this case.
It should be noted that if the other host is transmitting a packet, the
start of the waiting for next packet or waiting for ACK time-out time commences
from the end of its packet.
In the event of a transmission error, the receiver should send an ERR and
scan for an SOP that is not associated with another SOP or EOP. This wins
because EOP and SOP are specifically excluded from being op-codes. There is
still the problem of the noise condition ending between a pair of SOP's in a
quoting situation, however, in this case the packet as read is fairly certain to
violate protocol and be flushed, at the worse when an unexpected or missed EOP
occurs.
When an ERR is received the host should immediately stop sending its
current packet and start re-transmitting with the first unacknowledged packet
still pending. To prevent confusion, it should send an EOP after the incomplete
packet to prevent quoting problems.
CHECKSUM ALGORITHM
The packet checksum algorithm used is a cyclic redundancy check. Reading
the packet as a bit stream first the running sum is left shifted by 1, and if an
overflow occurs (ie, the 200000 bit is set) the input bit is complemented; and
if the resulting value is 1, the running sum is XOR'd with 2↑12.+2↑5.+1
(010041). The running sum initializes at 000000 for each packet.
The checksum includes all of the packet header variables and the entire
data area. It does NOT include the packet trailer or the SOP/EOP synch codes.
In PDP-10 assembly code, this is:
; CHKBIT adds a bit to the checksum in SUM.
;
; Call: MOVE BIT,<bit from data stream>
; PUSHJ P,CHKBIT
; <return>
CHKBYT: LSH SUM,1 ; SUM shifts left
TRZE SUM,1←16. ; Overflow set?
XORI BIT,1 ; XOR overflow with incoming bit
TRNE BIT,1 ; If the result is 1,
XORI SUM,1←12.+1←5+1 ; bring it in
POPJ P, ; Return to caller
For the PDP-11:
; CHKBIT adds a bit to the checksum in SUM.
;
; Call: MOV <bit from data stream>,BT
; JSR PC,CHKBIT
; <return>
CHKBIT: ASL SUM ; SUM shifts left
ADC BT ; XOR BT with high order bit of SUM
ROR BT ; If the result is 0,
BCC CHKRTN ; return to caller
MOV #010041,R0 ; Else get the polynomial
XOR R0,SUM ; and bring it in
CHKRTN: RTS PC ; Return to caller
PACKET FORMAT
_________________________________________
| PACKET HEADER |
|=======================================|
| |
byte 0 | SOP |
| |
|---------------------------------------|
| |
byte 1 | Op code |
| |
|---------------------------------------|
| |
byte 2 | Reserved * |
| |
|---------------------------------------|
| |
byte 3 | Packet number |
| |
|---------------------------------------|
| |
byte 4 | Data size (bytes) |
| |
|=======================================|
| PACKET DATA (optional) |
|=======================================|
| |
| |
| |
| |
byte 0 → | Data (<size> bytes) |
<size-1> | |
| |
| |
| |
|=======================================|
| PACKET TRAILER |
|=======================================|
| |
byte 0 | Packet checksum (low) |
| |
|- - - - - - - - - - - - - - - - - - - -|
| |
byte 1 | Packet checksum (high) |
| |
|---------------------------------------|
| |
byte 2 | EOP |
| |
|_______________________________________|
(*) Byte 2 of the packet header is reserved for future use and MUST be zero.
DCP's should ignore this byte on input.
From this diagram, it can be seen that the minimum packet size is 8. bytes
and the maximum is 263. bytes. At 1200. baud, transmission timings range from
.067 second to 2.2 seconds.
OP CODES
In the descriptions below, certain arguments are passed along with the
commands. These arguments are listed in the order in which they occur, along
with their byte size. They all occur in the DATA field of the packet.
The op codes corresponding to the values of SOP and EOP are specifically
illegal and are never used.
CODE 000 NOP NO-OP DCP ↔ DCP message
This command is a no-operation and should be ignored by the receiver except
that the packet still has to be acknowledged. It is used as an "idling" packet
to indicate that the sender is still alive but not transmitting anything.
CODE 001 RPC REQUEST PROCESS CONNECTION process → DCP message
8. Process ID of process to be connected to
2. (Optional) Initial allocation
This is the basic establish connection command. It serves a dual purpose;
to request establishing a connection, and to confirm establishing a connection.
The initial allocation is optional and defaults to infinity. However, unlike
the ALL op-code, an initial allocation of zero does NOT mean infinite
allocation; instead, it means no MSG's may be sent until an ALL is given.
CODE 002 CLS CLOSE PROCESS CONNECTION DCP → process message
This is the basic terminate connection command. It may either terminate an
existing connection or abort a request for one.
CODE 003 ALL ALLOCATE DCP → DCP message
2. Bytes of allocation
This is the data allocation command. The initial allocation is infinite.
If this feature is used, the receiver may send only up to the specified number
of data bytes in MSG packets before it must wait for a further allocation.
Sending an allocation of zero implies infinite allocation. This is for hosts
which are not confident of their ability to handle continuous data transmission
without buffer overflow. Allocation only applies to data in MSG packets; a host
must be ready to accept other packets at any time. Allocations are added to the
current allocation remaining.
CODE 004 MSG MESSAGE process ↔ process message
MSGSIZ Message passed to tertiary process
This is the basic data transmission command. The contents of the data part
are passed to the tertiary process. Data may be continuously sent until the
allocation runs out, after which no further MSG's may happen until another ALL
is given. Since packets as transmitted over DIALnet are sent in 8.-bit bytes it
is the responsibility of the tertiary protocol to do the necessary concatenation
or byte-loading and bit shifting for data with a byte size of other than 8.
bits.
OP CODES (continued)
CODE 005 ERR ERROR DCP ↔ DCP message
1. Error condition code:
000 Allocation has reached zero
001 Sent RPC when connection exists
002 Sent CLS when no connection exists
003 Sent ALL when no connection exists
004 Sent MSG when no connection exists
005 Sent ACK on meaningless packet
006 Packet checksum error
007 Packet violated protocol
010 Packet time-out
011 Packet received out of sequence
012 MSG exceeds allocation, wait for allocation
013 ALL received on an ∞ allocation connection
014 You seem to be dead, good bye
015 Phone connection crufty, good bye
016 SOP expected but something else received
017 EOP expected but something else received
020 Incomplete packet (SOP received)
021 Incomplete packet (EOP received)
022 Illegal op code
1. Packet sequence number of packet you are unhappy with
This is the command to tell the foreign host that it is losing with a
packet that it sent. The foreign host should examine the code and determine
what it is doing wrong. Code 000 does not indicate an error and means that
transmission is now frozen due to allocation reaching zero (ie, the sender is
waiting for a new allocation). Most of these codes indicate either a
transmission error or violation of network protocol. In the case of codes 014
and 015, the phone connection is immediately terminated after the ERR is sent.
CODE 006 ACK ACKNOWLEDGE, READY DCP ↔ DCP message
1. Packet sequence number of packet you are acknowledging.
2. (Optional) New allocation.
This command informs the foreign host that the packet with the specified
packet sequence number has be received successfully. It is also a request for
more packets to be sent; specifically it is a request for the packet with the
specified sequence number+1. If the optional allocation is specified, the
allocation is added to the current remaining allocation (unless this is a
repeated ACK, in which case it is ignored). ACK always has packet number 000.
CODE 007 RST RESET DCP ↔ DCP message
Close all connections, abort all processes. This command may be sent by a
host which has just been restarted following a service interruption. It
instructs the other host to forget all packets, connections, etc. RST is also
used in initially setting up a connection. RST always has packet number 000.
Once an RST is sent, no other packets (other than another RST) should be sent
until the acknowledgement comes in, and any received packet should be ignored.
OP CODES (continued)
CODE 010 BYE GOOD-BYE DCP ↔ DCP message
This command tells the foreign host that this is going to be the last
packet transmitted before the local host hangs up the phone. In addition, it
performs all the functions of RST. Following transmission (or receipt) of this
packet, both hosts should hang up.
CODE 011 IAM I CLAIM TO BE ... DCP ↔ DCP message
20. Phone number of this host
16. ASCII string with the name of this host
This command is used to tell the foreign who the local host claims to be.
It is up to the foreign host to believe it or not. The phone number is sent as
consecutive digits in binary. Telephone numbers in the USA should be sent as
three digit area code, followed by seven digit phone number.
ESTABLISHING AND BREAKING A CONNECTION
This is the basic mechanism in establishing a connection between two
tertiary processes in a duplex connection. In the discussion below, U refers to
the process which initially provokes the connection or USER, S refers to the the
process passively waiting for a connection or SERVER.
If a dialup connection has just been established, both hosts should start
with packet number 000. They should then proceed to send RSTs at each other
until both have received acknowledgements for their RSTs. After this, a
physical connection has been established and a process connection may be made.
It should be noted that until the physical connection has been established no
other packets (including ERR!!) should be sent. Bad data received should be
ignored until the RST/ACK synchronization has occured. Should synchronization
fail to occur within 120. seconds, the hosts may hang up.
Following the receipt of an ACK for its RST, each host should start sending
(and acknowledging) NOP's at each other until both have received and
acknowledged the other's NOP. This prevents problems with extra RST's still in
transit.
U must know the process ID of the S it wants to connect to. As far as
DIALnet is concerned, process ID's are arbitrary ASCII strings. However,
conventions have been established as noted elsewhere.
U instructs its DCP to send an RPC with the process ID at S it wants to
connect to.
The DCP at S's host passes the request along to S. S may have been
listening for a connection, or perhaps was created by the DCP as a result of the
RPC. If no such process exists or the DCP is unable to create the process, the
DCP should refuse the connection by sending back a CLS.
S then decides whether or not it wants to talk to U. If not, it instructs
the DCP to refuse the connection. Otherwise, it accepts the connection by
instructing its DCP to send an RPC back to U's DCP, with a zero process ID.
This RPC is sent as if S were trying to initiate a connection with U instead of
the other way around.
Once a connection has been established, the process ID is no longer used by
the host-host protocol.
The two hosts may then pass data back and forth between each other using
the MSG op-code. When a host wishes to terminate a connection, it sends a CLS.
Once a CLS has been sent, no further MSG's may be sent and any MSG sent is
to be replied to with an ERR. Of course, a new connection may be established
with RPC.
When a connection is terminated, the recepient of the CLS must send a CLS
to confirm terminating the process. This avoids timing errors and confusion
that could occur if both ends want to close at about the same time and both send
almost simultaneous CLS's. The result is that a received CLS is interpreted as
a confirmation despite whether it really was or wasn't spontaneous; in either
case no confirmation is needed.
EXAMPLES OF DIALNET INTERACTIONS
Please note that these examples are not meant to show the "only" way by
which these conditions can occur; rather it shows very simplified and perhaps
ideal interactions. Its main intent is to make some of the preceeding
paragraphs simpler and demonstrate how simple the DIALnet protocol actually is.
Acknowledgements are only shown for MSG packets, however all packets except
for ACK packets should be acknowledged. ACK packets are "acknowledged" by
sending more packets.
ESTABLISHING A CONNECTION REFUSING A CONNECTION
User Server User Server
RPC RPC
RPC CLS
BREAKING CONNECTION (BY USER) BREAKING CONNECTION (BY SERVER)
User Server User Server
CLS CLS
CLS CLS
NORMAL DATA TRANSMISSION NORMAL DATA TRANSMISSION
User Server User Server
MSG MSG
ACK ACK
DATA TRANSMISSION ERROR TIME OUT CONDITION
User Server User Server
MSG MSG 1
ERR MSG 2
MSG MSG 3
ACK MSG 1
ACK 1
GLOSSARY
The following terms are used in this document and are defined here to
remove ambiguity:
ACKNOWLEDGEMENT -- a verification packet stating that the specified packet was
sent properly.
ALLOCATION -- a 16.-bit quantity which specifies the number of bytes that may be
sent in MSG packets before a new allocation. This is to provide for
hosts with limited buffering. Allocation applies only to the data part
of MSG packets and not to any other type of packet.
BYTE -- an 8.-bit quantity. While DIALnet transmissions are to be considered as
a bit stream, this concept is convenient to use for many reasons.
BYTE SIZE -- this refers to the byte size of data as seen by the host computer.
All DIALnet transmissions should be considered bit stream transmissions
sent in units of 8.-bit bytes. All the DIALnet protocols except for the
FTP protocol use 8.-bit bytes.
CHECKSUM -- a 16.-bit quantity containing a CRC checksum of the packet.
CONNECTION -- a logical connection between two processes. Connections are
bidirectional.
DATA -- an arbitrary amount of data which is either used as arguments to the DCP
or as data to be passed to the processes utilizing DIALnet.
DATA COUNT -- a 8.-bit quantity indicating how many bytes are in the data field
of the packet. This quantity may be 000, in which case there is no data
field.
DIALNET -- a communications protocol for data transmission over standard phone
lines. This term also refers informally to the set of hosts which
implement DIALnet.
DIALNET CONTROL PROGRAM -- the process on each host responsible for the
host-host communications on that host. All the other processes on that
host send and receive their traffic through the DCP.
EOP -- an 8.-bit quantity indicating end of packet. The value of the EOP code
is 226 and it is a violation of protocol for a packet to end with
anything other than this code. Also, a packet can not be considered to
have been completely received until this code has been received. An EOP
that occurs at any other point must be quoted with an SOP.
HOST -- a system with DIALnet-compatible modems and DIALnet-support software
which knows the telephone number of at least one other host.
OP CODE -- a DIALnet host-host protocol operation code.
PACKET -- a logical unit of data transmitted over a DIALnet link. The packet is
the elementary unit of DIALnet transmissions. A packet is basically
data with a header and trailer.
GLOSSARY (continued)
PACKET ID -- an 8.-bit quantity which uniquely identifies a packet at a given
point in time. This is used to identify packets if necessary in error
recovery. Packet ID's may be recycled after both hosts have agreed that
the packet associated with this packet ID has been correctly sent and
received. Packet numbers start with 000 when a phone connection is
made, are incremented with each new packet, and wrap around to 000.
PROCESS -- an entity utilizing DIALnet. DIALnet traffic consists of
communications between processes.
PROCESS ID -- an ASCII string (currently 8. 8.-bit bytes) which uniquely
identifies the process.
SERVER -- the initially passive process in a connection. Note that a server is
not necessarily the receiver of the phone call, although this is
normally the case.
SOP -- an 8.-bit quantity indicating start of packet, included for redundancy.
The value of the SOP code is 227 and it is a violation of protocol for a
packet to begin with anything other than this code. Hence, unless a
packet is in the process of being transmitted, no other code other than
SOP should be transmitted or received. An SOP which occurs at any other
point must be quoted with an SOP.
TIMEOUT -- A wait time for a specified action. If the desired action does not
occur within a specified time, a "timeout" action is taken.
USER -- the initially active process in a connection. Note that a user is not
necessarily the initiator of the phone call, although this is normally
the case.
REFERENCES
The following documents describe communications protocols used in several
networks and are listed here for reference:
ARPAnet:
The world's first extensive packet-switched network.
[1] ARPAnet Protocol Handbook. Feinler and Postel (editors).
Also, these updates:
[a] RFC 726 Remote Controlled Transmission & Echoing
TELNET Option. Postel and Crocker.
[b] RFC 727 TELNET Logout Option. Crispin.
[c] RFC 732 TELNET Data Entry Terminal Option. Day.
[d] RFC 733 Standard for the Format of ARPA Network Text
Messages. Pogran, Vittal, Crocker, and Henderson.
[e] RFC 734 SUPDUP Protocol. Crispin.
[f] RFC 735 TELNET Byte Macro Option. Crocker and
Gumpertz.
[g] RFC 736 TELNET SUPDUP Option. Crispin.
[h] RFC 737 FTP Extension: XSEN. Harrenstien.
[i] RFC 738 Time Server. Harrenstien.
[2] Specifications for the Interconnection of a Host and an IMP,
BBN Report #1822.
Also, this update:
[a] RFC 716 Interim Revision to Appendix F of BBN Report
1822. Walden and Levin.
CHAOSnet:
The MIT Artificial Intelligence Laboratory local network.
[1] CHAOS ORDER. Moon.
DECnet:
A set of communications protocols designed by Digital Equipment
Corporation.
[1] Specification for: DDCMP (Digital Data Communications Message
Protocol). DEC.
[2] Specification for: NSP (Network Services Protocol). DEC.
[3] Specification for: DAP (Data Access Protocol). DEC.
LCSnet:
The MIT Laboratory for Computer Science local network.
[1] Local Network Notes. Pogran, et al.
PCnet:
A dial-type network oriented for hobbyist and personal computers.
[1] PCnet Communication Protocols. Crane, et al.
ACKNOWLEDGEMENTS
Les Earnest (SAIL), Mike Farmwald (SAIL), John McCarthy (SAIL), Dave Moon
(MIT), and Richard Stallman (MIT) provided invaluable encouragement and
assistance in designing (and debugging) this protocol and in proofreading this
document.
I take sole responsibility for whatever is inaccurate or unclear.